Today's more popular browsers, such as MICROSOFT'S INTERNET EXPLORER and MOZILLA FOUNDATION'S FIREFOX, use synchronous communications protocols, such as the Hypertext Transport Protocol (HTTP), to exchange information over the Internet. With a synchronous communications protocol, one entity in a network (e.g., the browser) makes a connection to another network entity (e.g., a web server), sends a request to the other entity, then waits for a reply before sending additional requests.
Synchronous communications protocols work well for supporting certain browsing tasks, such as when the browser sends a request to the web server for a web page, and then waits for a reply from the server to display the requested page. Other browsing tasks, however, are not carried out as efficiently using synchronous communications protocols. For example, an application, such as a web service, may need to notify the browser that an event has occurred. A method and protocol enabling this is disclosed in the cross-referenced U.S. patent application Ser. No. 11/160,612. In the supported protocols the web service does not need to wait for a response from the browser. However, allowing the Web service to send notifications without some form of pacing by either the browser or the Web service could result in published information associated with the notifications being presented at the browser too quickly for user to view or process.
Current methodologies for controlling flow in network protocols fail to provide a solution. For example, conventional network-level flow control occurs below the application layer of a network protocol. In this type of flow control, updates transmitted by a server are received on a client device and may be buffered in a network stack before being displayed in the application. If a user's application allows the display of the updates to be paused, the network stack may eventually run out of buffer space. This will trigger a flow control message in the client device that is sent to the server to request that the server stop sending updates. This type of flow control is based on system resource constraints, rather than by the control of the user or the application to pace the rate at which the updates are sent.
Current client-side caching also does not allow a user or application to pace the rate at which updates are sent and displayed. For example, conventional browsers and media players may make use of a cache for storing content received over a network from a server. However, this does not provide any type of flow control under direct control of the user, rather content is merely buffered in the cache on the client device. If the client runs out of cache space, older cached content is typically discarded to make room for new content. Further there is no ordering to the content in current browser caches. As in traditional flow control, this method is driven by system resource constraints and not controlled directly by user or application requirements.
A user can pace the rate of data received on a client device by using a request/response protocol, which is utilized in conventional browsers. Although, there is a one to one relationship between a request and a response containing the data, this type of protocol is unsuitable for receiving real-time data or data that is event generated. It is inefficient in that it requires the initiation of a separate request for each update/resource. The request/response protocol almost always requires the user to explicitly instruct the device to send the next request and thus is not useful where a passive mode of data reception is most appropriate.